From: [email-masked]
Date: Thu, 3 Jun 93 14:09:31 +0100

My comments to osi-prop.ps

In general:

	In the X/Open Peer-to-Peer Specification Chapter 7
	a Starter Set is defined. CPI-C also defines a starter set.
	But there is an important difference:

	In P2P it is possible to work only with the starter set functions,
	if the functional unit commit is selected.
	In CPI-C this is not possible. The program must use Set_Sync_Level.

	Therefore I make the following proposal:

	If CPI-C is used together with TX and tx_begin is called,
	the default value for Sync_Level should be CM_SYNC_POINT_NO_CONFIRM.

Page 4, Text point 4:

	Do we really need basic conversation in OSI TP protocol stack?
	Existing basic conversation programs basing on LU6.2 can
	not be simply ported to OSI TP because of 2 reasons:
     
	    a)  Set_Conversation_Type is needed at the remote application.
	    b)  Basic conversation LU6.2 programs can use the second part
		of the LLID field of GDS header to transport user data.
		This is not possible in OSI TP.

	So i suggest not to allow basic conversation in OSI TP environment.

Page 4, Text point 6a:

	The proposed solution makes it impossible to write portable
	programs (i.e. programs that can be ported from LU6.2 to OSI TP),
	if the call Set_Partner_LU_Name is used.

	In LU6.2 environment the program has to use Set_Partner_LU_Name.
	In OSI TP environment the program has to use Set_AP_Title.

	I make the following proposal:
	In OSI TP environment the Set_Partner_LU_Name is interpreted
	as a Set_AP_Title call with ap_title_format = CM_AP_DN.

	I know, this is no beautiful solution, but it allows to write
	portable programs.

Page 16, Text point 37c:

	The restriction that the value CM_ALLOCATE_CONFIRMED can
	only occur if sync_level has one of the values CM_SYNC_POINT
	or CM_SYNC_POINT_NO_CONFIRM may be wrong.

	For example the restriction does not exist at the Send_Data call 
	(see page 17, text point 39).

Page 27, first sentence:

	It is said that CMEAEQ extracts the own application-entity
	qualifier. This may me wrong, since on page 65 it is said
	that CMEAEQ extracts the Initiating-AE-Qualifier.

Page 57, table 3:

	I think CMCANC should also be mapped to TP-BEGIN-DIALOGUE rsp
	(result=rejected) if this is the first activity on the conversation
	following Accept or Accept_Incoming and allocate_confirm =
	CM_ALLOCATE_NO_CONFIRM.